step of displaying the completed form upon the user's browser 108 or 1 14 may be skipped. 
This can be made a user option with frequently-encountered forms. For example, when 
presented with a form for verification, the user may be given the option of requesting that a 
particular form, in the future, is to be filled out fully automatically without presenting the 
user with the completed form. 

[00052] The form fill proxy 400a or 400b returns the form to the form fill system 200a 
or 200b which then makes note of any changes made by the user and adjusts its internal 
databases and fuzzy logic so that it will be better able to fill out that same form when it is 
encountered in the future, as will be explained. 

[00053] In this manner, the system 100 automates the process of filling out personal 
information forms using a rules based dictionary and learns, over time, how to become better 
at the process of filling out such forms and how to quickly master new forms whenever they 
are encountered by using a fuzzy logic artificial intelligence system. 

[00054] There are two categories of data that can be filled in: Profile data (first name, 
last name, address, credit card information) are inserted into vendor checkout forms of the 
type just described. Non-profile data (typically a simple user name and password pair, or 
PIN, PKI certificate, etc.) are required to be submitted by many systems, such as Microsoft's 
Hot Mail electronic mail system, to identify a user each time he or she enters a web site. The 
first time a user receives a form requesting non-profile data, the user enters his or her chosen 
user name and password (PIN, etc.) manually. After that, such forms are automatically 
pre-filled by the present system without user intervention. 
DICTIONARY DATABASE 

[00055] The data structures or databases that underlie the operation of the present 
invention are shown in Figures 10-12. 

[00056] Figure 10 presents a high level description of the dictionary database 1000 
which contains the rules that are used to guide the filling out of forms. This database is 
initially pre-loaded with considerable information derived from numerous commercial forms 
on the Internet; and this information is revised and updated regularly as part of routine system 
support. In addition, and as a background task, the secure web pages on web sites known to 
be of interest can be periodically checked out for changes and alterations both in the names 
and in the contents of the secure web pages that contain forms to be filled out. The dictionary 
database 1000 may then be altered accordingly, possibly by simply deleting obsolete 
information or by removing page specific information to cause a page to be re-evaluated 
using artificial intelligence techniques. It is also possible to have a web crawler or spider 
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search out new priority sites on the Internet looking for other secure form pages to add to the 
database on an ongoing basis. 

[00057] The dictionary database 1000 contains a set of rules 1002. Each rule contains 
(illustratively enclosed within double quotation marks) the title or name of or label for an 
information field that may appear within a form along with the size of the space within that 
field where user information may be entered — how many typed characters the field can hold. 
This information is linked, by a symbolic name or a non-personal identifier (illustratively 
enclosed in outward pointing arrows used as quotation marks) to specific user information in 
the wallet database 1 100 that is to be inserted into that particular field. For example, Rule 1 
associates the tillable form field label "Name:" and field size "12" with a piece of personal 
information which, in the wallet database 1 100, assigned the non-personal identifier 
'<FirstName>'. Likewise, Rule 2, which is more complex in nature, associates the tillable 
form field labeled "Name" and of size "26" with a string of two user data values identified by 
non-personal identifiers taken from the wallet database 1 100 and conjoined together by a 
space, namely: '<FirstName> " " <LastName>', where the inserted space is enclosed within 
double quotation marks and the entire string value to be assigned to this field is enclosed with 
single quotation marks. (As those skilled in the art will recognize, the actual data base will 
use very different ways to represent all of these values and relationships.) In a similar 
manner, numerous rules contained within the dictionary database 1000 will associate 
numerous different fillable form field labels with different wallet database data values 
identified by some non-personal identifier or symbolic name assigned to the wallet database 
data values. 

[00058] Note that the rules applicable to different forms may sometimes conflict with 
one another. Two rules may assign different wallet data values to the same field label, since 
these rules may be used in conjunction with entirely different forms. Such ambiguities need 
to be resolved by the artificial intelligence system's fuzzy logic in the case of a 
newly-encountered form that the system may be called upon to try and fill in. 

[00059] The second part of the dictionary database, at 1004, are associations between 
the Internet addresses of particular forms and the rules that are applicable to those specific 
forms. For example, a secure form having a particular address on the Internet is associated 
with the Rules 1,3, and 4, as shown, meaning those are the rules that are to be used to control 
the completion of that particular form by the rules engine 220. 
WALLET DATABASE 
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[00060] Figure 1 1 describes the wallet database 1 100. In the preferred embodiment of 
the invention, the wallet database is an SQL relational database management system typically 
maintained on a separate and secure computer that may service several different form fill 
systems 200 such as the two 200a and 200b shown in Figure 1. As an alternative, the wallet 
database could belong to an individual user and be be a part of the user's browser 108 or 1 14 
or be a part of the user's PC 1 10 or wireless telephone or P.D.A. 106 or other user device, or 
it could be part of the operating system 1 12 or 1 18. The wallet database 1 100 could alswo be 
loaded on a special chip on a PC 1 10 or on a special phone or P.D.A. chip on a wireless 
telephone or P.D.A. 106. The wallet 1 100 does not have to be called a "wallet," but it can be 
any data base, having any name, that serves essentially the same purpose as the wallet 1 100. 
As another variation, the wallet database 1 100 may be a database containing equivalent 
personal information that is maintained by a third party. All of these, as well as other 
variations, come within the scope of the present invention. 

[00061] The actual interconnection between the wallet databases 1 100 and the form fill 
systems 200a or 200b in the preferred embodiment of the invention, and clearly not the only 
way possible of establishing such a connection, is by the wallet database 1 100 being designed 
to act as an Internet "client" to the form fill systems 200a and 200b, which act as "servers" to 
the wallet database. The wallet database 1 100, acting as "client", requests the form fill 
system 200a or 200b to provide it with a query of the wallet database 1 100. These calls to the 
form fill systems 200a and 200b made by the wallet database 1 100 are addressed to the 
common entry 202 (Figure 2) of the systems 200a and 200b in exactly the same manner as 
the way in which calls by the form fill proxies 400a and 400b, acting as clients, are addressed 
to the common entry 202 of the respective systems 200a and 200b. Thus, the form fill 
systems 200a and 200b have only one standard common entry 202 to which all requests 
from all clients are submitted. In response to requests received from the wallet database 
1 100, the form fill systems 200a and 200b simply hold the request until such time when there 
is a need to retrieve information relating to a particular user, at which point the wallet 
database 1 100 is called upon to provide the needed information, still acting as if it were a 
client (when it is really a server). 

[00062] As shown in Figure 11, every block of information within the wallet database 
1 100 begins with a user I.D. and a user password (or an equivalent PIN, PKI certificate, 
biometric, SIM Toolkit, etc) which must be provided, or else the data within the wallet is not 
provided and is kept secure. All communication with the wallet database 1 100 is done using 
secure Internet data transfer protocols to prevent interception and misuse of the personal data. 
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